Day 3 - 用 Claude Code 把 Prompt 變成可執行 Skill

同一張 FlowBoard 情境卡，丟一句「幫我分析」可能得到一篇泛泛建議；把工作交代清楚，才可能得到能檢查、能交接的成果。Prompt 的價值就在任務設計。

五個不能少的部分

一份工作型 Prompt 至少要回答五個問題：

1. 背景：產品、使用者與目前狀況是什麼？
2. 任務：要完成哪些動作？
3. 輸入：可以使用哪些資料？
4. 限制：哪些事不能做，資訊不足怎麼辦？
5. 輸出：交付格式與判準是什麼？

角色可以作為補充，例如請模型從產品研究角度檢查；但一句「你是世界級專家」不會增加證據，也不能保證專業判斷。比角色更重要的是把資料邊界和驗收方式說清楚。

Anthropic 官方 Prompt 指南也強調清楚、直接的指示與成功判準。下方五部分模板是作者針對產品工作整理的版本，不是模型通用保證。

「分析」也是危險的動詞。它可能指摘要、分類、比較、找矛盾或提出方案。改用可驗收動詞，例如「逐項抄錄畫面文字」「把 50 則回饋分群且保留編號」「列出每個推論所依據的觀察」。

從模糊要求改成任務

壞版本：

幫我分析 FlowBoard 的新手體驗，提出好功能。

它沒有資料來源，「好」也沒有判準。AI 很可能用常見模式補空白。

可執行版本：

背景：
FlowBoard 是教學用虛構 B2B 專案協作 SaaS，服務 10–50 人團隊。
研究題目是：新成員加入既有工作區後，不確定下一步該做什麼。

任務：
1. 只根據輸入，整理已知事實與待驗證假設。
2. 找出還缺哪些資料，才能判斷問題發生在哪個步驟。
3. 把缺口改寫成可調查的問題，不提出功能。

輸入：
【貼上 Day 2 產品情境卡】

限制：
- 案例資料皆為教學用模擬資料。
- 不使用未提供的產品、市場或使用者資訊。
- 不把客服回饋推論成多數使用者行為。
- 資訊不足時寫「無法判斷」，並說明缺什麼。

輸出：
A. 事實／假設／限制三欄表
B. 最多 5 個資料缺口
C. 每個缺口對應 1 個研究問題

範例輸出

研究問題可以是：「新成員第一次登入後，完成哪些事件才會回到產品？」不能寫成「導覽能提升多少留存」，因為那已預設方案與結果。

通用任務型 Prompt 模板

背景：
【產品、目標使用者、工作情境、這份產出的用途】

任務：
請依序完成：
1. 【可觀察、可驗收的動作】
2. 【下一個動作】

輸入：
【貼上原始資料；保留編號或來源】

限制：
- 只能使用輸入與指定來源。
- 不得把推論寫成事實。
- 不確定時標記「待確認」，並列出所需資料。
- 【產品、時間、政策或格式限制】

輸出：
【表格／清單／文件】
必須包含【欄位或段落】。
每個結論須附【原文編號／畫面元素／數據欄位】作為依據。

完成前自我檢查：
- 是否遺漏任何輸入？
- 是否違反限制？
- 哪些內容最需要人類決策？

大型任務不要一次要求「研究、決策、寫 PRD」。拆成數個中間產出，才能在錯誤擴散前攔截。先擷取，再分類，再推論，最後才提出候選方案。

也可以為每個中間產出寫驗收條件。以回饋分類為例：所有 ID 都出現且不重複；每個群組至少引用一則原文；無法判斷的內容不得自行補齊。驗收條件比「請仔細分析」更有效，因為人與 AI 都知道什麼叫完成。若工具支援結構化輸出，也仍要抽查內容，欄位格式正確不代表判斷正確。

迭代 Prompt，不是反覆抽卡

結果不理想時，不要只按重新生成。先診斷失敗原因：輸入少了角色資訊？任務動詞太寬？輸出沒有要求保留來源？接著只修改對應欄位，並保存版本差異。

版本：v1
失敗：把「可能影響」寫成確定因果
修改：要求每列標記事實／推論，推論附依據
結果：可追溯，但仍缺事件數據

人類需要檢查什麼

檢查輸入是否合法且足夠；每個結論能否指回原文；模型是否把常識或訓練資料混入案例；格式完整是否掩蓋證據不足。若任務牽涉定價、法規、資安或重大產品決策，應找領域負責人與一手資料確認。

Prompt 只能降低誤解，無法保證答案正確。真正的品質來自可追溯輸入、明確限制與人工驗收。

在團隊中，最好連同 Prompt 保存輸入版本、模型或工具名稱、執行日期與人工修改。當兩次結果不同時，才能分辨是資料、指令、工具版本或審查標準改變，而不是憑印象挑一份比較順眼的答案。

今天的產出物

今天完成的是上方的通用任務型 Prompt 模板。請把 Day 2 情境卡放進模板跑一次，確認模型會保留「事實、假設、限制」的界線。

明天我們把這套任務設計用在競品截圖。輸入將從文字卡片換成畫面，但原則相同：先描述看見什麼，再說可能代表什麼，不能把推測偽裝成產品事實。

在 Claude Code 建立任務設計 Skill

今天把五個部分寫進專案級 Skill，讓之後每個產品任務都先經過同一套檢查：

mkdir -p .claude/skills/task-design

建立 .claude/skills/task-design/SKILL.md：

---
name: task-design
description: 把產品工作拆成背景、任務、輸入、限制與輸出。當使用者提出模糊的分析、整理或產生要求時使用。
---

收到模糊任務時，先補齊背景、任務、輸入、限制與輸出。
不要用常識補造產品資料；缺資料時列為待確認。
先輸出缺口，再提供可執行版本。

在 Claude Code 中輸入：

/task-design 幫我分析 FlowBoard 新成員啟用問題

預期結果不是一篇泛泛分析，而是一份指出輸入缺口、驗收方式和可直接執行任務的草稿。實際執行後，Claude Code 不會直接開始分析，而是先把缺口列出來：

接著才是補齊後的任務書，背景、任務、輸入、限制、輸出五段齊全，連交付物要標哪些資訊都寫清楚：

「缺口清單」與輸入欄的「待確認」標記，就是 Skill 規則有被套用的痕跡。如果只看到一篇漂亮答案，卻看不出規則參與其中，這份輸出還不夠有證據力。

明天會把這個方法套到競品畫面，讓 Claude Code 只根據截圖可見內容工作。

參考資料

• Anthropic Claude Platform Docs：Prompting best practices